1. Field of the Invention
Embodiments of the present invention generally relate to interaction of applications and dynamic libraries. More particularly, embodiments of the present invention relate to the field of reducing interference among applications co-located in a process when using dynamic libraries.
2. Related Art
Executing multiple applications in a single operating system process (or process) can lead to improved scalability. However, such co-located applications can interfere with one another as they share global states of dynamically loaded libraries. For instance, if two applications A and B depend on and use a dynamic library libcount.so containing the following code:
static int count=0;
void increase_count( ){count++;}
int get_count( ){return count;}
then when both applications A and B execute in the same process they may see incorrect value returned by get_count( ). This is so because applications A and B each expect to be the sole user of libcount.so, as they would if each executed in its own separate process.
One way around this is to re-code libcount.so so that the variable count is virtualized—each application gets its own copy of it. Accessing the correct copy of the variable count is determined by the accessing application's identifier as follows:
static int count=[MAX_APPS];
extern int current_app_id( );
void increase_count( ){count[current_app_id( )]++;}
int get_count( ) {return count[current_app_id( )];}
There are several problems with this approach. First, the manual work such re-coding requires is proportional to the number of global variables and the number of places they are used in (although this can be somewhat mitigated by using macro definitions). Second, the source code of the dynamic library in question is always required. Third, each access to a global variable requires getting the current application's identifier.
These disadvantages can be quite problematic. Sources of libraries are not always available, and even if they are, they can be quite large, requiring lots of work to make them multi-application safe. The third disadvantage may not be so important, since getting an application identifier can boil down to several machine instructions.
Additionally, core native libraries of a virtual machine such as the conventional Java virtual machine (JVM) have been written with an implicit assumption that only one application will be using them at any given time within an instance of a virtual machine. The conventional JVM does not support interference-free interactions between core native libraries and applications co-located in the same process.